The present invention relates generally to computer database systems, and more particularly to an improved method of monitoring changes in values of attributes of objects in an object-oriented database system by means of tuned monitors.
In an object-oriented database system, an "object" is a kind of entity An object has certain "attributes" or characteristics, associated with it. A "view" of an object is a set of some of the attributes associated with that object. To "materialize" a certain view respecting a given object means to provide the values of those attributes which make up that view.
Some attributes have values which are stored in the database; these attributes are accessed by retrieving them from storage. An "extensional" function is a procedure which is used for retrieving such values from storage. Other attributes have values which are not stored but rather are derived (by computation or the like) as needed; an "intensional" function is a procedure which is used for deriving such values (and which has no undesired side effects).
For example, an employer might have a database system for keeping certain information about its employees. Each employee would be known to the database system as an "object" of type EMPLOYEE. The database might include values for each of the following attributes of an EMPLOYEE object:
NAME PA0 DATE OF BIRTH PA0 HOME ADDRESS PA0 MONTHLY SALARY PA0 HIRE DATE PA0 NAME: Bill Johnson PA0 BIRTH DATE: Apr. 5, 1960 PA0 HOME ADDRESS: 123 Main Street, Palo Alto, Calif. 94303 PA0 MONTHLY SALARY: $2,500.00 PA0 HIRE DATE: Nov. 20, 1985
(In addition, the system gives each employee a unique identifier so that two employees having the same name can easily be distinguished.)
As already noted, some attributes can be derived from others. For example, every employee has an AGE, but if the system knows an employee's birthdate it can easily compute that employee's age. Therefore, to save space and to preserve system integrity only the value of the employee's birthdate is stored in the database; the employee's age is computed whenever it is needed.
An employee named Bill Johnson might be represented by the following attribute values in the database:
One "view" of an employee might consist only of the employee's name and address. Such a view might be used, for example, to have the computer print an envelope in which a notice to employees would be mailed. To "materialize" this view for a given employee it would be necessary to call two extensional functions--"Name" and "Address"--which would return the values of the attributes NAME and ADDRESS of the designated employee.
Another view of an employee might consist of the employee's name, age, monthly salary and number of years with the company. This view might be used, for example, to calculate how much to credit to the employee's retirement account. To materialize this view it would be necessary to call two extensional functions--"Name" and "Monthly Salary"--and two intensional functions--"Age" and "Number of Years with Company." The two intensional functions would return the required values of the attributes AGE and NUMBER OF YEARS WITH COMPANY by performing computations on other values returned by extensional or other intensional functions and which ultimately are derived from values which are stored in the database.
A typical computer system includes a central processing unit, a main memory, storage media such as magnetic disks, a terminal which includes for example a keyboard and a monitor screen, and a plurality of workstations. Each workstation comprises a terminal and usually a local processing unit and memory as well. Users at the various workstations use the computer to perform a variety of tasks.
A "client" of a database system is an applications program which interacts with the database system. Such a client program may be executed by the central processor or by a local processing unit in a workstation. A user may be running a plurality of client programs simultaneously.
Occasions may arise when a client needs to be alerted if certain values in the database are changed. In the example of the employee database discussed above, at one workstation a client program might be updating the database with respect to various financial matters, including the amount to deposit in each employee's retirement account for the previous month, while at a different workstation (possibly hundreds of miles away) another client program might be updating the database by posting all the salary raises which were granted during that month. The first client program must be alerted if anything done by either program results in changes in the values of financial data respecting one of the employees on whose retirement account the first client is then working.
More generally, a notification that a monitored value has changed may be needed for any of a number of purposes. A client may wish to be alerted if an abnormal condition occurs. The occurrence of a certain condition or set of conditions may be a signal to start running a certain application program. A graphic display may need to be updated whenever there is a change in a parameter being displayed. A client may need to recompute certain other values which depend on the value which has just changed (as in the above example of the employee retirement account).
Monitoring imposes a heavy computational and input/output overhead on a database system, especially if the system is large and a number of values are being monitored at the same time for several different clients. Various methods have been proposed to minimize this overhead. For example, in one such system an "alerter" is called if specified boolean conditions are satisfied (O. P. Buneman and E. K. Clemons, "Efficiently Monitoring Relational Databases," ACM Transactions on Database Systems 4, 3, Sep. 1979, pp 368-382). A "retrieve always" mechanism in another system causes queries to be re-executed upon each update to specified relations (M. Stonebraker, "Triggers and Inference in Database Systems," in M. Brodie and J. Mylopoulos (eds.), On Knowledge Based Management Systems, Springer-Verlag, 1986).
Systems of "triggers" have been proposed for relational database systems; such triggers typically invoke a database procedure upon updates of user-specified base relations (see, for example, M. Astrahan et al., "System R: A Relational Approach to Database Management," ACM TRansactions on Database Systems, 1 (2), June 1976). Some examples of systems including triggers are Sybase, proposed by Darnovsky et al., Transact-SQL User's Guide, Sybase Inc., 2910 7th Street, Berkeley Calif. 94710, 1988, and HiPac, proposed by McCarthy et al., "The Architecture of an Active Database Management System", Proc. SIGMOD, Portland, Oreg., 1989, pages 215-224 and by Dayal et al., "Rules Are Objects Too: A Knowledge Model for an Active, Object-Oriented Database System", Advances in Object-Oriented Database Systems, 2nd International Workshop on Object-Oriented Database Systems, Sept. 1988, pages 129-143. HiPac provides a "coupling mode" between a trigger and a set of actions on a database. The coupling mode controls when a trigger is executed relative to a triggering condition. The trigger, in other words, is action oriented rather than value oriented and connects its coupling mode to the updating action.
A technique which is somewhat similar to the trigger system is the use of a "declarative integrity constraint," in which a proffered update to the database is rejected if specified boolean conditions are not satisfied at commit time (see, for example, M. Stonebraker, "Implementation of Integrity Constraints and Views by Query Modification," Proc. ACM SIGMOD Conf., San Jose, Calif., May 1975).
Another technique, access-oriented programming, is implemented in some object-oriented languages such as "LOOPS". A message to set values of instance variables is intercepted by means of a user-provided trigger procedure which may in turn set or display some other value (M. J. Stefik et al., "Integrating Access-Oriented Programming Into a Multiparadigm Environment," IEEE Software 3, 10, Jan. 1986, pp. 10-18). The trigger procedures are dynamically added and removed from running systems to avoid interfering with other system logic (K. Osterbye, "Active Objects: An Access Oriented Framework for Object-Oriented Languages," Journal of Object-Oriented Programming, Vol. 1, No. 2, June/July 1988, pp. 6-10).
Expert systems such as "SYNTEL" and "OPS5" provide a method of monitoring virtual memory data retrieved from persistent data (R. Reboh and T. Risch, "Syntel: Knowledge Programming Using Functional Representations," Proc. AAAI-86, Philadelphia, Pa., August 1986, pub. Morgan Kaufman, Los Altos, Calif., 1986, pp. 1003-1007).
A method of monitoring changes in attribute values of objects in an object-oriented database system is disclosed in the aforementioned U.S. Patent. By way of example, an object-oriented database system is described in Fishman et al., "Overview of the IRIS DBMS" in Kim and Lochovsky, Object-Oriented Concepts, Databases, and Applications, ACM Press, 1989. The IRIS database management system will be referred to occasionally herein for convenience to exemplify the teachings of the aforesaid U.S. Patent and of the present invention, but it will be understood that neither the aforesaid Patent nor the present invention is to be limited to the IRIS system.
The method as taught in the aforesaid U.S. Patent interacts cooperatively with client programs to provide a localized method of (a) monitoring an object in an interactive, object-oriented database system in response to a request from a client program and (b) invoking an application procedure designated by the client if a change in a monitored attribute value is detected. High-overhead tasks are performed at times when monitoring is not taking place so as to minimize any overhead imposed on the system during actual monitoring. The invoked procedure is sometimes referred to herein as the "tracking procedure" ("tracker" for short) because it "tracks"--that is, is invoked by a change in--the monitored attribute.
A preferred embodiment of that method includes keeping records of any request from a client to monitor an attribute of an object in the database, any interdependence relationships between the monitored attribute and other attributes, the value of the attribute being monitored, this latter record being kept by accessing the interdependence record, and any update transactions initiated by a client during an update session.
When the initiating client requests that the transaction be committed, the system determines which monitored attributes may have been affected and then determines whether the values of any of said attributes have in fact changed. For each value which has changed, the system notifies any client which had requested monitoring of that attribute. The client which requests the commit is notified during the process of determining whether the values have changed. Other clients are notified after the update has been committed to the database.
Alternatively, any client may at any time request notification of any changes that have occurred in any monitored attributes subsequent to a previous notification. The event which triggers notification is the notification request as opposed to the request to commit an update, and only the requesting client receives the notifications.
"Notifying" a client means interrupting any task then being performed by the client and invoking a predesignated tracking procedure. The tracking procedure is an application program procedure that is called by the database system when a result change has been detected. Thus the tracker is part of the application program and is ordinarily written in the same language as that program. The database system does not send data to the tracker when a result change has occurred; instead, the tracker can freely access the database to retrieve the current result of the monitored query. Thus, change detection (invoking the tracker) is distinguished from retrieving the new result.
If the client is not in an interruptible state when a change in a monitored attribute is detected, a record is kept of notifications intended for that client until the client enters an interruptible state or requests notification.
In the IRIS database system a parameterized query (a query having a set of actual parameters) is called a "derived function". A derived function is access-path-optimized for arbitrary parameters similar to canned queries in relational database systems as described in Chamberlin et al., "Support for Repetitive Transactions and Ad Hoc Queries in System R" Transactions on Database Systems, Vol. 6, No. 1, March 1981, pp 70-94. In IRIS, object attributes are modeled by derived functions where the first parameter typically is bound to the object identifier. For example, a certain derived function might retrieve the highest paid employee for any given department.
If a first process commits (stores in the database) an update, a tracker of a second process will be invoked asynchronously if the update changes the result of a query being monitored by the second process. Monitoring processes are autonomous from updating processes; this means that the committing transaction does not wait for the tracking procedure to finish.
A database monitor can be compiled once for a given query, as discussed in the aforesaid patent and in Risch, "Monitoring Database Objects" in Proceedings of the 15th Conference on Very Large Databases (Amsterdam, Holland) 1989, pp. 445-453. Activating a monitor in an application process informs the database system that it must henceforth invoke the tracker whenever a result change is detected for a given query and parameters. A monitor is deactivated either explicitly or when the process is terminated.
If the tracker is invoked exactly every time there is a result change, as disclosed in the aforesaid patent, there is "perfect tracking". In practice it may not be possible or desirable to achieve perfect tracking. Accordingly, there is a need for a way to adjust the tracking in such a way that client programs are notified of changes in monitored attributes neither more nor less often than is desirable.